Subject: Response to CPIC comments

From: "Hildebrand, Jeff" <[email-masked]>
Date: Wed, 03 Aug 94 10:05:00 PDT

Guys,
Thanks for the comments.  I have been working on the document so
these have taken longer than I expected.
I will be putting the document out on the server tommorrow - I
hope given Rich gets back to work.

BIG ISSUE:  Can we actually get to the MAP NAME GDS variable from
MC-ALLOCATE & MC SEND?RECEIVE_EXPEDITED?
Hope to hear from you soon.
Thanks,
Jeff
 --------------------------------

Data Connection Comments
Substance:

1.   CMSMDX perhaps rename 'map_name' to 'map_id' or something
as it is not a name but rather an integer.  Presumably, this id has only
local
significance.
Response:
In response to Peter's comments it seems to be more appropriate to use
have an alpha-numeric identifier.  I will change Map_name to be alpha
and include a map_name_length parameter.

2.   It may be better not to refer to the map_name (or map_id) as an
integer because 'integer' it means different things to different people.
Maybe specify 'a value between 1 and 32767' to minimize confusion.
Response:
Refer to above response
3.   Is CM_OPERATION_INCOMPLETE valid for CMSMDX?
Response:
It is not there for the regular  send expedited data call, and that makes
sense since the amount of data is so small and any delay would defeat
the reason one would use the call.

4.   For consistency with CMSMDX, should CMRMVX be renamed
CMRMDX?  Also
Response
I have changed the name to CMRMDX

5.   Perhaps rename CMRCM and CMSNDM to CMRCVM and
CMSENDM (as they are simpler extensions of the base verbs CMRCV
and CMSEND).
Response:
I would like to leave the names they way they are.  I tried to have
longer names before and was told I could not.  I will recheck this.
6.   The overview for CMSNDM refers to ASN.1 - do the majority of
the intended readership know what ASN.1 is?
Response:
The OSI people, including X/OPEN, expect ASN.1 to be a
predominate encoding method.  This does not preclude other encoding
methods.  OSI specifically addresses the use of other encoding
methods when describing how to define a transfer syntax.

7.   From an implementation point of view, I'm not clear how the
receiving CPI-C end knows what the map name in force is since one
can specify a different map name on each send.
Response:
When the program is written a specific interface will have been chosen
for each connection it expects to maintain.  The LU 6.2 CRM is
responsible for converting the global map name to the local map name.
The U-ASE of the OSI TP CRM determines what

8.   The CPI-C Send_Initialization_Data call has a send data limit of
10000 bytes.  I'm not sure if this is some arbitrary limit or whether it
has something to do with real limits on the amount of data that can be
sent on an Allocate.  If the latter is the case then presumably the 10000
byte limit will refer to the post-transformation data and the pre-
transformation limit will be some arbitrary value (probably less than
10000).  Can we guarantee that 10000 bytes will be valid for
CMSMID?
Response
An implementation can allow a user to send however much data it
deems appropriate.  The OSI TP profiles require a receiver to accept 0
 - 10K+ octets so the real requirement is on the receiver and not the
sender.  I realize this is kinda backwards, but it allows a sender to
behave pretty much how it wants.  Therefore the 10K allocate limit
could be construed either way, though I would tend towards the 10K
pre-transformation definition.

Typographical errors:

1.   Some of the verb calling format boxes needs to be corrected, e.g.
CMSMID shows CMSMDX.
Response
Fixed.
That's it for now.

Regards, john.

 ---------------------- Peter Binninger's comments --------------------
Here are some comments to Jeff's new proposal for mapped
conversations.

 - There are 3 places in appendix D saying that CPI-C does not support
MAP_NAMEs. We need to change all 3 places.
  - page 398
  - page 399
  - page 402

Response
Fixed, in the mapping changes the receive and send verbs are
duplicated with support for map name.   Also refer to question on map
name support for expedited data.

 - As mentioned by Jeff the OSI TP mapping needs update.
Response
Done
 - We need changes in the include file cpic.h
Response
done
 - Table 7 on page 38 needs updates.
Response
done
 - We need new secondary return codes.
 Response
done
 - We need new call_ids (page 319 and include files)
Response
Done
 - We need the definition of map_name in table 18 (page 329)

 - We need updates to the possible values of
control_information_received   (page 319 and include files), for
example CM_EXPEDITED_MAPPED_DATA_AVAILABLE
Response
 Done, though I suspect you can think of more.
 - we need updates to the possible values of return_code   (page 319 and
include files), for example CM_UNKNOWN_MAP_NAME
Response
 Done
 - nearly all format descriptions in the proposal use wrong abbreviations
for example CMEID instead of CMEMID on page 36
Response
Fixed - but please check me.
 - we need a parameter received_length on the Receive_Mapped_Data
call  - some parts of the proposal describe the map_name as a 1-64
character   name, some as an integer. It should be a character name
with character  set 00640.
Response
Made them all character strings.  They should probably be T61 strings
so the Japanese character set can be represented.
Peter Binninger
Here are some more comments to Jeff's new proposal for mapped
conversations.

 - If the map_name is a 1-64 character name, we need an additional
parameter map_name_length in all CPI-C calls containing map_name.
An alternative would be to define the map name as an 8 byte  character
string (similar to sym_dest_name).
Response
Done - length added
 - Page 3 of the proposal contains the SET_MAP_NAME and
EXTRACT_MAP_NAME   calls from the former proposal.
Response
fixed
 - In an OSI TP environment the encode/decode routine must know the
abstract   syntax and the transfer syntax. Since the transfer syntax is
negotiated  between the two application entities CPI-C users cannot
know the  transfer syntax.
  A possible implementation would be:  The system administrator
configures map_names. To each map_name he  assigns an
encode/decode routine and an abstract syntax name.  The encode
routine can find out the abstract syntax from the map_name.  The
routine must ask the CRM which transfer syntax was negotiated  on
this association for this abstract syntax. Then the routine can  make the
encoding.
  The decode routine gets the transfer syntax and abstract syntax from
the CRM. The CRM finds out the map_name from the abstract syntax
and  gives it to the CPI-C user.
  Do I have the right understanding? Are there other possible
implementations?  I think the CPI-C document should contain some
sentences like these.
Response
The program knows everything it needs to know about encoding and
decoding data because it knows the application context it is using.  The
map routine is the U-ASE and as such, is described in the application
context definition.  The management of presentation contexts is the
sole concern of the U-ASE so any presentation context switching can
only be done by the U-ASE.
I envision a map routine as being constructed in the following manner:
1.   The application context U-ASE definition specifies three
things:
A.   The ASN.1 or other encoding specification.
B.   The transfer syntax to be used, i.e. 8825 Basic
Encoding Rules
C.   Application program data structure definitions.
2.   The system administrator builds a map routine to properly
encode and decode the application data structures.  A map
name is associated with each application data structure.
Because ASN.1 is self defining, the receiver can discover
which data record it has received and branch to the routine that
will create the proper application data structure and fill in the
map_name variable with the proper identifier.  Sending data is
the reverse of this process.
I am unsure about what should be in the document as it may be too
close to specifying a solution rather than a function.

 - We need a description of the new return_code values in appendix B.
Response
Done

 -----------------------------------------------------------------------------
Peter Binninger                         Voice: (+49) 7531-87-4758
Computer Gesellschaft Konstanz mbH      Fax:   (+49) 7531-87-4888
(Siemens Nixdorf Informationssysteme)   Email:
[email-masked]
Max-Stromeyer-Strasse 116
78467 Konstanz
Germany